The present invention relates to wireless personal area networks and wireless local area networks. More particularly, the present invention relates to systems, methods, devices, and computer program products for controlling transmitted power and transmission rate in a wireless personal area network or wireless local area network environment.
The International Standards Organization's (ISO) Open Systems Interconnection (OSI) standard provides a seven-layered hierarchy between an end user and a physical device through which different systems can communicate. Each layer is responsible for different tasks, and the OSI standard specifies the interaction between layers, as well as between devices complying with the standard.
FIG. 1 shows the hierarchy of the seven-layered OSI standard. As seen in FIG. 1, the OSI standard 100 includes a physical layer 110, a data link layer 120, a network layer 130, a transport layer 140, a session layer 150, a presentation layer 160, and an application layer 170.
The physical (PHY) layer 110 conveys the bit stream through the network at the electrical, mechanical, functional, and procedural level. It provides the hardware means of sending and receiving data on a carrier. The data link layer 120 describes the representation of bits on the physical medium and the format of messages on the medium, sending blocks of data (such as frames) with proper synchronization. The networking layer 130 handles the routing and forwarding of the data to proper destinations, maintaining and terminating connections. The transport layer 140 manages the end-to-end control and error checking to ensure complete data transfer. The session layer 150 sets up, coordinates, and terminates conversations, exchanges, and dialogs between the applications at each end. The presentation layer 160 converts incoming and outgoing data from one presentation format to another. The application layer 170 is where communication partners are identified, quality of service is identified, user authentication and privacy are considered, and any constraints on data syntax are identified.
The IEEE 802 Committee has developed a three-layer architecture for local networks that roughly corresponds to the physical layer 110 and the data link layer 120 of the OSI standard 100. FIG. 2 shows the IEEE 802 standard 200.
As shown in FIG. 2, the IEEE 802 standard 200 includes a physical (PHY) layer 210, a media access control (MAC) layer 220, and a logical link control (LLC) layer 225. The PHY layer 210 operates essentially as the PHY Layer 110 in the OSI standard 100. The MAC and LLC layers 220 and 225 share the functions of the data link layer 120 in the OSI standard 100. The LLC layer 225 places data into frames that can be communicated at the PHY layer 210; and the MAC layer 220 manages communication over the data link, sending data frames and receiving acknowledgement (ACK) frames. Together the MAC and LLC layers 220 and 225 are responsible for error checking as well as retransmission of frames that are not received and acknowledged.
FIG. 3 is a block diagram of a wireless network 300 that could use the IEEE 802.15 standard 200. In a preferred embodiment the network 300 is a wireless personal area network (WPAN), or piconet. However, it should be understood that the present invention also applies to other settings where bandwidth is to be shared among several users, such as, for example, wireless local area networks (WLAN), or any other appropriate wireless network.
When the term piconet is used, it refers to a network of devices connected in an ad hoc fashion, having one device act as a controller (i.e., it functions as a master) while the other devices follow the instructions of the controller (i.e., they function as slaves). The controller can be a designated device, or simply one of the devices chosen to function as a controller. One primary difference between devices and the controller is that the controller must be able to communicate with all of the devices in the network, while the various devices need not be able to communicate with all of the other devices.
As shown in FIG. 3, the network 300 includes a controller 310 and a plurality of devices 321–325. The controller 310 serves to control the operation of the network 300. As noted above, the system of controller 310 and devices 321–325 may be called a piconet, in which case the controller 310 may be referred to as a piconet controller (PNC). Each of the devices 321–325 must be connected to the controller 310 via primary wireless links 330, and may also be connected to one or more other devices 321–325 via secondary wireless links 340. Each device 321–325 of the network 300 may be a different wireless device, for example, a digital still camera, a digital video camera, a personal data assistant (PDA), a digital music player, or other personal wireless device.
In some embodiments the controller 310 may be the same sort of device as any of the devices 321–325, except with the additional functionality for controlling the system and the requirement that it communicate with every device 321–325 in the network 300. In other embodiments the controller 310 may be a separate designated control device.
The various devices 321–325 are confined to a usable physical area 350, which is set based on the extent to which the controller 310 can successfully communicate with each of the devices 321–325. Any device 321–325 that is able to communicate with the controller 310 (and vice versa) is within the usable area 350 of the network 300. As noted, however, it is not necessary for every device 321–325 in the network 300 to communicate with every other device 321–325.
FIG. 4 is a block diagram of a controller 310 or a device 321–325 from the network 300 of FIG. 3. As shown in FIG. 4, each controller 310 or device 321–325 includes a physical (PHY) layer 410, a media access control (MAC) layer 420, a set of upper layers 430, and a management entity 440.
The PHY layer 410 communicates with the rest of the network 300 via a primary or secondary wireless link 330 or 340. It generates and receives data in a transmittable data format and converts it to and from a format usable through the MAC layer 420. The MAC layer 420 serves as an interface between the data formats required by the PHY layer 410 and those required by the upper layers 430. The upper layers 205 include the functionality of the device 321–325. These upper layers 430 may include TCP/IP, TCP, UDP, RTP, IP, LLC, or the like.
Typically, the controller 310 and the devices 321–325 in a WPAN share the same bandwidth. Accordingly, the controller 310 coordinates the sharing of that bandwidth. Standards have been developed to establish protocols for sharing bandwidth in a wireless personal area network (WPAN) setting. For example, the IEEE standard 802.15.3 provides a specification for the PHY layer 410 and the MAC layer 420 in such a setting where bandwidth is shared using time division multiple access (TDMA). Using this standard, the MAC layer 420 defines frames and super-frames through which the sharing of the bandwidth by the devices 321–325 is managed by the controller 310 and/or the devices 321–325.
Preferred embodiments of the present invention will be described below. And while the embodiments described herein will be in the context of a WPAN (or piconet), it should be understood that the present invention also applies to other settings where bandwidth is to be shared among several users, such as, for example, wireless local area networks (WLAN), or any other appropriate wireless network.
FIG. 5 illustrates a data transmission scheme 500 in which information is transmitted through a network 300 including a plurality of MAC super-frames 505 each including guaranteed time slots (GTSs), according to a preferred embodiment of the present invention. Preferably the super-frames 505 are of a set length to allow various devices in the network to coordinate with a network controller or other devices in the network.
As shown in FIG. 5, the data transmission scheme 500 includes transmitting successive super-frames 505 in time across the network 300. Each super-frame 505 includes a beacon 510, an optional contention access period (CAP) 515, and a contention free period (CFP) 520. The contention free period 520 may include one or more management time slots (MTSs) 525 and one or more guaranteed time slots (GTSs) 530.
The super-frame 505 itself is a fixed time construct that is repeated in time. The specific duration of the super-frame 505 is described in the beacon 510. In actuality the beacon 510 includes information regarding how often the beacon 510 is repeated, which effectively corresponds to the duration of the super-frame 505. The beacon 510 also contains information regarding the network 300, such as the identity of the transmitter and receiver of each slot, and the identity of the controller 310.
In the preferred embodiment there are as many guaranteed time slots 530 as there are primary and secondary wireless links 330 and 340. However, this may change in alternate embodiments. There may be greater or fewer guaranteed time slots 530 than there are devices 321–325. In this case the controller 310 will designate how the devices 321–325 should use the available guaranteed time slots 530.
The controller 310 uses the beacon 515 to coordinate the scheduling of the individual devices 321–325 into their respective guaranteed time slots 530. All devices 321–325 listen to the controller 310 during the beacon period 510. Each device 321–325 will receive zero or more guaranteed time slots 530, being notified of each start time and duration from the controller 310 during the beacon period 510. Channel time allocation (CTA) fields in the beacon 510 include start times, packet duration, source device ID, destination device ID, and a stream index. This beacon information uses what is often called TLV format, which stands for type, length, and value. As a result, each device knows when to transmit and when to receive. In all other times the device 321–325 may cease listening and go into a power conservation mode. The beacon period 510, therefore, is used to coordinate the transmitting and receiving of the devices 321–325.
The controller 310 sends the beacon 510 to all of the devices 321–325 at the beginning of each super-frame 505. The beacon 510 tells each device 321–325 the duration or super-frame 505 as well as other information about its MAC address, e.g., the size and duration of the contention access period 515, if that is used, and the duration of the contention free period 520.
Each beacon will contain information that is not precisely a CTA. One piece of information will define the beacon period 510 and describe the start time and the duration for the beacon period 510. Another will define the contention access period 515 and describe the start time and the duration for the contention access period 515. Each beacon can also have multiple CTAs. There will be a CTA for each of the management time slots 525 and guaranteed time slots 530. Using dynamic time slots, the slot assignments can change every super-frame with modified CTAs.
During transmission, each device 321–325 must hear the beacon 510 so that it will know what time slots have been assigned to it as either a transmitter or receiver. If the device misses the beacon, it must listen to the entire super-frame just in case it is receiving data. Furthermore, it cannot transmit for the duration of the super-frame because it does not know when it is permitted to transmit. This is detrimental to the system because it leads to interruptions in data transmission.
The network can pass control and administrative information between the controller 310 and the various devices 321–325 through the optional contention access period 515, the management time slots 525, or both. For example, this can involve information about new devices that want to join the network 300. The particular implementation will determine what particular option is used: it could include a contention access period 515, one or more management time slots 525, or some combination of both.
Management time slots 525 can be downlink time slots in which information is sent from the controller 310 to the devices 321–325, or uplink time slots in which information is sent from the devices 321–325 to the controller 310. In this preferred embodiment two management time slots 525 are used per super-frame, one uplink and one downlink, though alternate embodiments could choose different numbers of management time slots and mixtures of uplink and downlink.
If a new device 321–325 desires to be added to the network 300, it requests entry from the controller 310 either in the optional contention access period 330 or in one of the management time slots 525. If a particular device 321–325 has no need to coordinate with the controller 310 during the optional contention access period 515 or the management time slots 525, that device 321–325 may remain silent during the optional contention access period 515 or the management time slots 525. In this case that device 321–325 need not even listen to the controller 310 during the optional contention access period 515 or the management time slots 525, and may go into a power-conserving “sleep” mode.
Individual devices then transmit data packets during the contention free period 340. The devices 321–325 use the guaranteed time slots 530 assigned to them to transmit data packets 535 to other devices (which may include the controller 310 if the controller 310 is also a device 321–325 within the network 300). Each device 321–325 may send one or more packets of data 535, and may request an immediate acknowledgement (ACK) frame 540 from the recipient device 321–325 indicating that the packet was successfully received, or may request a delayed (grouped) acknowledgement. If an immediate ACK frame 540 is requested, the transmitting device 321–325 should allocate sufficient time in the guaranteed time slot 530 to allow for the ACK frame 540 to arrive.
It is necessary to organize which devices 321–325 will be transmitting and which will be listening to avoid collisions of transmitted data. For example if device one 321 and device four 324 both try and transmit data at the same time, this data may collide and cause the receiving devices to fail in acquiring and receiving the signal.
The reason we allocate individual time slots 530 in the super-frame 505 is because when a given device, e.g., device one 321, is transmitting to another device, e.g., device five 325, it's really broadcasting its signal to everyone, i.e., broadcasting on the open air where anyone who happens to be listening can hear. We would prefer that while device one 321 was transmitting, device five 325 was the only device that was listening. This is basically a TDMA approach. Since the broadcast medium is wireless, when one device is transmitting the system has to limit who else can use the channel.
Since each particular device 321–325 knows its transmit start time and duration from information received during the beacon period 510, each device 321–325 can remain silent until it is its turn to transmit. Moreover, a given device 321–325 need not listen during any guaranteed time slot periods 530 in which it is not assigned to either transmit or receive, and may enter into a power conservation mode. Since the time periods corresponding to each guaranteed time slot 530 have been fully coordinated by the controller 310 during the beacon period 510, individual devices 321–325 know when not to listen.
The guaranteed time slots 530 shown in this embodiment may be of differing sizes. The starting times and durations of the guaranteed time slots 530 are determined by the controller 310 and sent to the devices 321–325 during the contention access period 330 or one of the management time slots 525, as implemented.
In this embodiment a guaranteed time slot 530 is shown as having a plurality of data packets 535 and associated ACK frames 540. Generally there is also a delay period 545 between the data packets 535 and ACK frames 540, and between a final acknowledgement 540 and the end of the guaranteed time slot 530.
Each one of these data packets 535 will preferably have a source device ID (e.g. address) and a destination device ID (e.g. address). Thus, each individual packet will have its own identifier.
This can lead to problems if a device 321–325 misses the beacon 510. First, a device 321–325 that misses the beacon 510 will have to listen for the entire duration of the super-frame 505 in case another device 321–325 is transmitting to it. This eliminates any chance for the device 321–325 to go into a low power mode. Second, a device 321–325 that misses the beacon 510 cannot transmit during the entire duration of the super-frame 505, even if it was assigned a GTS 530, because it won't know when that assigned slot 530 is.
In embodiments without a CAP 515 or an MTS 525, it may be desirable to put in a delay between the beacon 510 and the first GTS 530, to allow individual devices 321–325 time to process the beacon 510. Otherwise the devices 321–325 assigned to the first GTS 530 may not enter into a transmission/listening mode in time to use the assigned slot 530.
It may also be desirable to make certain that the first GTS 530 is available for use by low power devices so that they can listen to the beacon 510, listen to their assigned GTS 530 and they go to sleep right away.
A problem with this system, however, is that it can lead to significant transmission errors if the devices 321–325 cannot properly receive the beacons 510. If the time slots 530 are totally dynamic, each device 321–325 must properly receive a beacon 510 for every super-frame 505 or suffer the disadvantages listed above. This could lead to a dead air rate proportional to the beacon rate. A beacon error rate of 10−4 would correspond to average of an interruption once per minute. Such an error rate would be unacceptable for many applications, and would require additional buffering to make up for the losses, which would serve to increase the cost of the device 321–325.
However, if a device 321–325 has the timing information for the super-frame 505, but just didn't get the new slot assignments, i.e., it only partially received the header, it will have the use of timing information but not the use of slot assignment information. Or, since there is a maximum amount of drift between devices 321–325 and the controller 310, a device 321–325 can transmit if it knows the CTAs, even if it completely misses the beacon, for up to some finite number of beacons. This can lead to a tenfold improvement in error rate, or from roughly once a minute to once every ten minutes. This shows that there can be significant improvement by having the slot assignment stay the same.
It is possible to use this fact advantageously if the system uses static GTSs 530, i.e., GTSs that don't change in location or duration. In this case, since each device knows where and when the GTSs 530 are, and who was assigned to them in the last super-frame 505, all that is lost is the knowledge of whether the assignment of devices 321–325 to the time slots 530 has been changed.
Thus, if devices 321–325 fail only if they miss successive beacons 510, e.g., if they miss two in a row, three in a row, etc., the system can dramatically improve the time between transmission stoppages due to corrupt headers 510. So by allowing more and more header errors, the system can greatly reduce the probability that it will not be able to transmit.
A problem with using static GTSs 530 is that the assigned time slots 530 can become poorly allocated. This can cause a loss in transmission speed because of wasted time, and may make it difficult to accommodate adjacent networks that may need time allocated in larger durations.
Furthermore, if two networks are set up side-by-side, it becomes necessary to coordinate the two networks so that they don't interfere with each other, but each also has its bandwidth requirements met.